The present invention relates generally to software system performance diagnosis, and more particularly, to blackbox memory monitoring with a calling context memory map and semantic extraction.
Many software problems come from memory problems. Understanding the structure of memory objects is critical to determine the root-cause of memory errors. For example, knowing the memory address ranges and checking the overruns is an effective method to detect buffer overflow.
Also knowing the details of runtime memory status can help the management of software systems or performance debugging. For instance, by knowing the size of queues or the number of memory objects for transactions on the fly in the program, we can understand how busy the program is or whether there is any problem in the process workflow precisely based on the data status.
While there have been several approaches in the debugging stage (e.g., memory profiling), they are not directly applicable to the deployment stage due to the concern on performance.
With respect to how others have attempted to solve the problem, the following references are discussed below. [1] Nicholas Nethercote and Julian Seward, “Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation”, In proceedings of ACM SIGPLAN 2007 Conference on Programming Language Design and Implementation (PLDI 2007), San Diego, Calif., USA, June 2007. [2] VisualVM: http://visualvm.java.net/features.html.
Valgrind [1] uses raw calling context (i.e., call stack information) extracted from the call stack at the allocation of memory objects to profile memory usages. This technique is called stack walking and it is generally expensive in terms of speed and storage. Walking call stack to extract the context is slow to perform at runtime. A representation of a call stack is a list of call sites with a varying size depending on the call depth. It makes the storage of context information inefficient.
VisualVM [2] is a visual tool to profile and analyze Java programs. It provides a memory profiler which presents the class names of live allocated objects. While the class names represent the identification of objects, this information is not enough to track back the root-cause understanding what code allocates this object.
Accordingly, there is a need for blackbox memory monitoring with a calling context memory map and semantic extraction.